\subsection{Dynamic Binding}
\label{sec:dynamic-binding}

With our security rules, it is possible to define a permission for $R_1$ like the following: \textsf{perm}($\mathsf{r_1}$, \textsf{doctor}, \textsf{consult}, \textsf{file}, \textsf{owned\_patients}). However in this rule, no precise meaning is attached to the context \texttt{owned\_patient}. Similarly, in the \texttt{ActionDeclaration} declared in \S \ref{sec:StaticRules}, how both methods \texttt{deleteFile} declared in their respective classes exactly interact is still unspecified. Dynamic bindings allow these tasks to be specified using predicates. These predicates are then evaluated against a model representing an application's dynamic state, as defined in Sec. \ref{sec:DynamicState}, for the Decision Logic to manage the policies. 

From Fig. \ref{fig:SpecificationLanguage}, a \texttt{DynamicBinding} is either a \texttt{ContextBinding} or an \texttt{Operation\-Binding}. Both share the same structure: a \texttt{DynamicBinding} defines a \texttt{predicate} formula for the binding, which refers to a \texttt{source} that performs an \texttt{action} on a \texttt{target}. Additionally, a \texttt{ContextBinding} references a \texttt{ContextId} to be defined. 

Figure \ref{fig:predicate} describes the predicate language for dynamic binding. Compared to the metamodel of Fig. \ref{fig:dynamic-state}, it is very similar to \texttt{Event}'s subclasses, except that artifacts to be find in the dynamic state are replaced by placeholders (i.e. free variables). An \texttt{InstanceOf} maps an \texttt{InstanceVar} to an exising \texttt{Role} in the policy; a \texttt{FieldOf} maps an \texttt{InstanceVar} to a \texttt{Field} (name) and its \texttt{Value}, possibly using primitive operations (like arithmetic or boolean operations, collection operators, or primitive types operations). A \texttt{MethodCall} maps a method identifier with a method alias as defined in static mappings in Sec. \ref{sec:StaticRules}. Naturally, well-formedness rules exist, which allow writing correct predicates based on the Java and policy declarations (e.g., if a field is declared having type \textsf{int}, it has to be matched with an integer value). 


\begin{figure}[t]
	\center
	\resizebox{\textwidth}{!}{\includegraphics{Predicate.png}}	
	\caption{Predicate Language for Dynamic Binding}
	\label{fig:predicate}
\end{figure}



%
 %defines the metamodel for \texttt{DynamicBindingRule}s. Such a rule is either a \texttt{ContextBinding} or an \texttt{ActionBinding}. From Fig. \ref{fig:rules}, remember that a security rule needs an activation context, and that state-based rules additionally require one. A \texttt{ContextBinding} allows to attach to a \texttt{ContextId} a \texttt{Predicate} that defines when this identifier is enabled, or hold. \moussa{Provide example for a particular \texttt{ContextId}}. An \textsf{ActionBinding} allows to attach to \textsf{Action}'s names defined with a \texttt{StaticRule} the particular context when it is activated, i.e. the exact configuration of instances involved and parameter values that makes the method sequence realise the policy action. Consider for example the mapping given in Sec. \ref{sec:StaticRules}: \textsf{\textbf{action} delete\_file 
%\textbf{methodId} deleteService, deleteDB \textbf{sig} \texttt{*.Service.deleteFile(int, String, int) -> *.DB.deleteFile(File)}}. Then \texttt{delete\_file} is considered performed in the policy if the aliased method of \texttt{deleteService} has a caller instance (\texttt{source}) \textsf{src} that is mapped to the (unique) parameter of the method aliased to \texttt{deleteDB}.



%Hold rules enable the definition of state conditions that affect the application of security rule by adding constraints over the subject, action and target of security rules. The set of conditions defined by every hold rule is identified by a (basic) context identifier. Figure \ref{figure_predicate} describes the structure of a hold rule. The conditions of a hold rule is a predicate expression. A predicate expression is a logic formula composed using predicates presented in Section~\ref{section_application_state}, in addition to {\it rule state} predicates. Rule state predicates, shown below, allow the definition of contexts that hold depending on the state of other security rules. 

%\begin{table}
%\centering
%%\caption{Rule State Predicates}
%\begin{tabular}{p{3cm} l}
%\toprule 
%{\bf Predicate} &  {\bf Informal Meaning} \\ 
%
 %\midrule
 %%{\it inact\_per(i,s,a,t)}& the rule $i$ allowing $s$ to take $a$ on $o$ is inactive\\
%
 %{\it act\_perm(i,s,a,t)}& $i$ allows $s$ to take $a$ on $t$\\
%
 %%{\it inact\_pro(i,s,a,t)}& the rule $i$ forbidding $s$ to take $a$ on $o$ is inactive\\
%
 %{\it act\_proh(i,s,a,t)}& $i$ forbids $s$ to take $a$ on $t$\\
%
%%{\it inact\_obl(i,s,a,t)}& $i$ requiring $s$ takes $a$ on~$t$ is inactive\\
%
%{\it act\_obl(i,s,a,t)} & $s$ is obliged by $i$ to take $a$ on~$t$\\
%
%{\it viol\_obl(i,s,a,t)}& $s$ has violated $i$ but $i$ is still required\\
%
%{\it fulf\_obl(i,s,a,t)}& $s$ has fulfilled $i$ and $i$ is not required\\
%
%{\it fviol\_obl(i,s,a,t)}& $s$ has fulfilled $i$ after $i$ was violated\\
%
%%\midrule 
%
%%\multicolumn{2}{c}{$i\in \m{I}$, $\;\;s,t\in \m{O}$, $\;\;a\in \m{A}$, $\;\;r\in\m{R}$}\\% , $\;\; c\in \m{C}$ }\\
%
%\bottomrule 
%
%\end{tabular} 
%\label{table:rulestatepredicates}
%
%\end{table}
%

In the concrete syntax, a hold rule is specified in the form of a (Prolog) logic rule of the following form:

\crsl{$hold(S,A,T,C) \leftarrow F$.}

\noindent A proposition of this form is read as follows: the context {\it C} holds between the subject {\it S}, action {\it A} and target {\it T} of a security rule if the formula {\it F} holds. A rule is well-formed if every variable appearing in the head of the rule (the rule's left-hand side) or in a negated predicate in the body (the rule's right-hand side) also appears positively in the body. For example, consider the following rule:

\crttl{$hold(D,\_,F,personal\_doctor) \leftarrow$}
{$ instance\_of(D,doctor),instance\_of(F,file),$}
{$ attribute(F,patient\_name,N), attribute(D,patient\_names,includes,N)$.}


\noindent The previous rule specifies that the context {\it personal\_doctor} holds between a doctor {\it D} and a file {\it F} of a security rule if {\it D} is a {\it doctor}, {\it F} is a file, {\it N} is the value of the attribute {\it patient\_name} of {\it F} and {\it N} is included in the doctor's list of the patients ({\it patient\_names} of {\it D}).



\begin{figure}
\center
\includegraphics[width=10cm]{predicate.pdf} 
\caption{Dynamic Assignment: Hold Rules}
\label{figure_predicate}
\end{figure}

%\paragraph{Usage Control Support} Usage control~\cite{Park2004} introduces pre, ongoing and post controls in the form of obligations to cover requirements not covered by contextual access control models. Examples of usage controls are a pre-obligation to accept the service usage terms before access, an ongoing obligation to keep an ad window open while watching a movie and a post-obligation to pay for resource usage after access ends. In our framework, usage control specification is based on the {\it rule state} predicates. More precisely, by enabling activation and deactivation of permissions/obligations based on the state of obligation/permission rules, we are able to cover these typical usage control requirements.


\subsection{Operation Rules}
\label{section_operation_rules}

 The operation rules specify a relationship between method calls and a policy operation, i.e. a subject taking an action on a target. They have a similar structure to hold rules and are specified as follows:

\crsl{$operation(S,A,T) \leftarrow F$.}
 


\noindent For example, consider the delete file action which corresponds to consecutive execution of the {\it deleteService} and {\it deleteDB} methods as presented in Section~\ref{section_action_declaration_java}. In this case, the subject is the doctor and the target is the file. In these methods, the doctor may be identified as being the calling instance of {\it deleteService} whereas the file appears as the parameter of the method {\it deleteDB}. This can be specified using an operation rule as follows: 

 \crdl{$operation(S,delete\_file,T) \leftarrow method(M,deleteService),$} {$attribute(M,this,S), method(M1,deleteDB), attribute(M1,1,T)$.}

\noindent The rule above specifies that the method calls {\it deleteService, deleteDB} correspond to taking the policy action {\it delete\_file} by a subject {\it S} on a target {\it T} where {\it S} is the calling instance of {\it deleteService} and {\it T} is the first parameter of {\it deleteDB}. 


